L’échec du modèle Spotify

Il y a des articles comme cela qui chamboulent un peu les idées reçues et qui permettent de prendre un peu de recul.

C’est le cas de « Spotify’s Failed #SquadGoals » publié le 19/04/2020 par Jeremiah Lee qui décrit de l’intérieur les difficultés rencontrées par Spotify dans la mise en oeuvre de sa propre organisation. Il nous invite (comme beaucoup d’autres avant lui) à ne pas les imiter mais surtout à en tirer les leçons, qu’il nous partage généreusement, ainsi que bon nombre de ressources supplémentaires.

En voici une traduction pour permettre une diffusion un peu plus large dans la communauté française, tout en gardant en tête qu’il n’y a pas de solution miracle mais que sa recherche peut nous amener à de belles découvertes et à de belles histoires. Bonne lecture !

Note : le post initial est sous licence Creative Commons Attribution-ShareAlike 4.0 International license. Tout le crédit est donc à attribuer à Jeremiah pour son travail.

Début de traduction

Spotify n’utilise pas le « modèle Spotify » et vous ne devriez pas non plus.

De tous les attraits de la culture startup, peu sont plus désirables que la vitesse et l’agilité d’une petite équipe. Maintenir ce sentiment dans une société qui croît est un challenge. En 2012, Spotify a partagé sa manière de travaillé et a suggéré qu’ils avaient réussi.¹

J’étais excité de voir le modèle Spotify en action lorsque j’ai passé un entretien pour un rôle en product management à leurs quartiers généraux de Stockholm en 2017. Cependant, la recruteuse m’a surpris avant le premier entretien. Elle me mis en garde de ne pas m’attendre à ce que Spotify soit une utopie Agile.

J’ai rejoins la société après qu’elle ait triplé de taille à 3000 personnes sur 18 mois. J’ai appris que le fameux modèle de squad n’était seulement qu’une ambition et n’avait jamais été entièrement mis en oeuvre. J’ai été témoin d’un chaos organisationnel alors que les leaders de la société étaient en transition incrémentale vers des structures de management plus traditionnelles.

Lorsque j’ai demandé à mes collègues pourquoi le contenu n’avait pas été supprimé ou mis à jour pour refléter la réalité, je n’ai jamais reçu de bonne réponse. De nombreuses personnes pensaient ironiquement que les articles étaient excellents pour le recrutement. Je ne travaille plus à Spotify, alors je partage mon expérience pour remettre les pendules à l’heure. Le modèle de squad de Spotify a échoué à Spotify et il échouera dans votre société aussi.

Mais vous n’avez pas à me croire sur parole

Le co-auteur du modèle Spotify² et de multiples coachs agile ayant travaillé à Spotify ont dit aux gens de ne pas le copier depuis des années. Malheureusement, la vérité ne se répand pas aussi rapidement ou aussi largement qu’une idée en laquelle les gens veulent croire.

Même au moment où on l’a écrit, on n’était pas en train de le faire. C’était moitié ambition, moitié approximation. Les gens ont vraiment lutté pour copier quelque chose qui n’a jamais vraiment existé. 

—Joakim Sundén, coach agile à Spotify (2011–2017)

Cela m’inquiète lorsque les gens regardent ce que l’on fait et pensent que c’est un framework qu’ils peuvent juste copier et implémenter. … On essaie vraiment de souligner le fait que l’on a des problèmes également. Ce n’est pas « scintillant comme si tout marchait bien et que toutes nos squads étaient super fantastiques.

—Anders Ivarsson, co-auteur du livre blanc de Spotify³

Récapitulatif

Vous pouvez lire et regarder le contenu original en moins de 30 minutes ou sauter à la prochaine section si vous y êtes déjà familiers. Voici un bref résumé.

Spotify avait des équipes appelées squads parce-que ça sonnait mieux (sans plaisanter). Un groupe d’équipes étaient organisées dans un département appelé tribe (tribu). Chaque équipe était prévue pour être une mini-startup autonome, avec un product manager agissant comme un mini-CEO pour son domaine de fonctionnalité. Les équipes avaient des designers et des ingénieurs logiciel avec un éventail de spécialisations. L’intention était qu’une équipe devrait avoir toutes les compétences nécessaires sans avoir besoin de compter sur une autre équipe pour réussir.

Les product managers avaient une structure de management traditionnelle. Un product manager pour une équipe rapportait au product director de leur département (« tribe lead »). Pareil pour les designers. Les ingénieurs logiciel, cependant, étaient managés en dehors de la structure d’équipe.

Les “Chapter leads” manageaient les ingénieurs logiciels spécialisés dans un type spécifique de développement logiciel au sein du département. Par exemple, tous les ingénieurs logiciel travaillant sur des APIs backend dans toutes les équipes au sein du département auraient un manager et tous les ingénieurs Android mobile dans le département auraient un manager différent. L’intention était de permettre aux ingénieurs d’être déplacés entre les équipes au sein du département pour répondre au mieux aux enjeux business sans avoir à changer de manager.

Spotify a essayé une structure matricielle d’équipe de grande longévité avec des choix de mots inhabituels.¹ Cela n’a pas bien fonctionné.

Pourquoi cela n’a pas marché

1. Le management matriciel a résolu le mauvais problème
2. On s’est concentré sur l’autonomie de l’équipe
3. La collaboration était une compétence supposée
4. La mythologie devint difficile à changer

1. Le management matriciel a résolu le mauvais problème

L’équipe agile « full stack » marchait bien, mais le management matriciel des ingénieurs logiciels a introduit plus de problèmes qu’il n’en a résolu.

• Les équipes à Spotify étaient plutôt de grande longévité. Le bénéfice de ne pas avoir à changer de manager lorsque l’on bouge dans une autre équipe était limité.

• Les managers d’ingénierie dans ce modèle avaient peu de responsabilité au-delà du développement de la carrière des personnes qu’ils manageaient. Même dans ce cas, leur capacité à aider dans le développement des compétences interpersonnelles était limité. Un manager d’ingénieur ne managerait pas assez les autres personnes de l’équipe ou ne serait pas assez impliqué dans le contexte quotidien pour évaluer les conflits au sein de l’équipe de manière indépendante.

Sans un seul manager d’ingénierie responsable des ingénieurs dans l’équipe, le product manager manquait d’une pair équivalent – un mini-CTO pour leur rôle de mini-CEO. Il n’y avait pas une seule personne responsable (accountable) pour la production de l’équipe d’ingénierie ou qui pouvait négocier la priorisation du travail à un niveau équivalent de responsabilité.

Lorsqu’un désaccord au sein de l’équipe d’ingénierie survenait, le product manager avait besoin de négocier avec tous les ingénieurs de l’équipe. Si les ingénieurs ne pouvaient pas atteindre de consensus, le product manager avait besoin d’escalader à autant de managers d’ingénierie qu’il y avait de spécialisations d’ingénierie dans l’équipe. Une équipe avec des ingénieurs backend, application Web et application mobile aurait au minimum 3 managers d’ingénierie à impliquer. Si ces managers d’ingénierie ne pouvaient pas atteindre de consensus, un unique problème d’équipe aurait à escalader au directeur du département de l’ingénierie.

Les Chapter leads sont des leaders-serviteurs qui vous aident à grandir en tant qu’individu. Ils ne travaillent pas vraiment avec les équipes. Ils ont des subalternes dans toutes les équipes. Ils n’ont pas vraiment de responsabilité (accountability) pour la production. Ils ne prennent pas cette responsabilité. Il est facile de voir le product owner comme le manager de l’équipe.

—Joakim Sundén, coach agile à Spotify⁴

Apprendre des erreurs de Spotify : Une équipe produit (designers/ingénieurs) contient typiquement plus d’ingénieurs que de designers ou product managers. Avoir un seul manager d’ingénierie pour les ingénieurs dans l’équipe crée un chemin d’escalade de responsabilité pour les conflits au sein de l’équipe. Les product managers devraient avoir un pair équivalent pour l’ingénierie. Les products managers devraient être responsables (accountable) pour la priorisation du travail. Les managers d’ingénierie devraient être responsables (accountable) pour la réalisation des ingénieurs, ce qui inclut être capable de négocier les compromis de vitesse et de qualité avec le product manager.

2. Spotify s’est concentré sur l’autonomie d’équipe

Quand une société est petite, les équipes doivent traiter un large éventail de travail pour produire et doivent shifter d’initiatives fréquemment. Lorsqu’elle grandit d’une startup à une scale-up, les fonctions dupliquées dans les équipes se déplacent dans de nouvelles équipes dédiées pour augmenter l’efficacité de l’organisation en réduisant la duplication. Avec plus d’équipes, le besoin d’une équipe de shifter d’initiative diminue en fréquence. Ces 2 changements permettent aux équipes de penser plus profondément et à plus long terme aux problèmes auxquels ils sont sujets à résoudre. Une iteration plus rapide, cependant, n’est pas garantie. Chaque responsabilité qu’une équipe cède pour améliorer le focus devient une nouvelle dépendance cross-équipe.

Spotify n’a pas défini de processus commun pour la collaboration cross-équipe. Permettre à chaque équipe d’avoir son propre mode de fonctionnement signifiait que chaque équipe avait besoin d’un mode d’engagement unique pour collaborer. La productivité globale de l’organisation en a souffert.

Le modèle Spotify a été documenté quand Spotify était une société bien plus petite. Il était prévu que ce soit une série en plusieurs partie, selon Anders Ivarsson. L’autonomie avait fait la première coupe, mais les autres parties sur l’alignement et la responsabilité (accountability) n’ont jamais été terminées.

Apprendre des erreurs de Spotify : L’autonomie nécessite l’alignement. Les priorités de l’entreprise doivent être définies par le leadership. L’autonomie ne veut pas dire que les équipes peuvent faire tout ce qu’elles veulent. Les processus pour la collaboration inter-équipes doivent être définis. L’autonomie ne veut pas dire laisser les équipes s’auto-organiser pour chaque problème. La manière dont le succès est mesuré doit être défini par le leadership pour que les personnes puissent négocier efficacement la priorisation de dépendance inter-équipe L’autonomie nécessite la responsabilité (accountability). Le product management est responsable (accountable) pour la valeur. L’équipe est responsable (accountable) pour la production d’incréments « terminés ». Les équipes matures peuvent justifier de leur interdépendance avec leur capacité à articuler la valeur business, le risque, l’apprentissage et leur prochain mouvement optimal.6

Si je devais faire une chose différemment, je dirais que l’on ne devrait pas tant se concentrer sur l’autonomie.

Chaque fois que vous avez une nouvelle équipe, ils doivent réinventer la roue sur la manière dont ils devraient travailler. Peut-être, seulement peut-être, que l’on devrait avoir une « agilité minimum viable ». Vous commencez avec ça. Vous êtes libres d’en sortir, mais les personnes ne devraient pas avoir à en sortir tout le temps.

À quel moment commencez-vous à insérer ce processus ? Probablement quand c’est trop tard.

—Joakim Sundén, agile coach at Spotify⁴

Henrik Kniberg parlait de la manière dont on était pas bon pour les grandes initiatives et on est toujours pas très bon pour les grandes initiatives.

Si vous avez des manières de travailler incohérentes, c’est plus difficile pour les gens de bouger. Si c’est plus difficile pour les gens de bouger, il est plus probable que vous avez des manières de travailler incohérentes. Cela va juste se renforcer jusqu’à ce que tout d’un coup, vous ne travailliez plus pour la même société. Vous travaillez pour ces sortes de sous-cultures bizarres.

—Jason Yip, coach agile à Spotify (2015–date d’écriture)⁵

3. La collaboration était une compétence supposée

Alors que que Spotify donnait le contrôle aux équipes sur leur manière de travailler, de nombreuses personnes n’avaient pas les connaissances de base des pratiques Agile. Cela résulta en équipes itérant sur des ajustements de processus dans un espoir aveuglé de trouver la combinaison qui les aiderait à améliorer leur production. Les personnes manquaient d’un langage commun pour discuter efficacement des problèmes de processus, des instructions pour les résoudre, et de l’expérience pour évaluer la performance. Ce n’était pas très agile. Ce n’était juste pas de la cascade (not-waterfall).

Les “coachs Agile” étaient des consultants internes que Spotify fournissait aux équipes pour enseigner et suggérer des améliorations de processus. Alors que les intentions étaient bonnes, il n’y avait pas assez de coachs pour aider chaque équipe. Un engagement de coach avec une équipe était rarement suffisamment long pour tenir jusqu’à la fin du projet pour aider l’équipe à évaluer sa performance. De plus, ils n’étaient responsables (accountable) pour rien.

Le contrôle sans la compétence est le chaos.

—L. David Marquet, Turn the Ship Around!

Apprendre des erreurs de Spotify : La collaboration est une compétence qui nécessite connaissance et pratique. Les managers ne devraient pas supposer que les gens ont une compréhension existantes des pratiques Agile. Lorsqu’une société devient suffisamment grande, les équipes vont avoir besoin d’un support dédié pour guider la planification au sein de l’équipe et structurer la collaboration entre les équipes. Le management de programme peut être responsable (accountable) pour le processus de planification. Les managers de programme dédiés catalysent les équipes de la même manière que les product managers et managers de l’ingénierie le font avec leurs compétences respectives.

4. La mythologie est difficile à changer

Quand Scrum a introduit de nouvelles significations à un tas de mots comme burn-down et sprint, il l’a fait parce-que cela introduisait de nouveaux concepts nécessitant des noms. Spotify a introduit le vocabulaire de missions, tribes (tribus), squads, guilds (guildes), et chapter leads pour décrire sa manière de travailler. Cela donna l’illusion qu’ils avaient créé quelque-chose méritant d’apprendre des choix de mots inhabituels.

Cependant, si l’on enlève les synonymes non nécessaires des idées, le modèle Spotify se révèle comme étant un ensemble d’équipes cross-fonctionnelles avec trop d’autonomie et une structure de management médiocre. Ne vous faites pas avoir. Si Spotify s’était référé à ces idées par leurs noms originels, peut-être qu’ils auraient pu les évaluer plus justement lorsqu’ils ont échoué plutôt que de devoir se confronter à changer leur identité culturelle simplement pour trouver des processus internes qui marchaient bien.

Apprendre des erreurs de Spotify : La plupart des entreprises peuvent seulement maintenir un certain nombre de domaines d’innovation. Un processus interne est rarement le premier domaine d’innovation qui différencie une société sur le marché. L’étude du passé permet aux entreprises de choisir de meilleurs domaines d’innovation. Optimisez pour la connaissance. Chaque nouvelle chose qu’une personne doit apprendre pour être productive dans votre organisation devrait être évaluée sur sa valeur. Les termes Business units, départements, équipes, et managers communiquent plus efficacement les rôles et responsabilités de la structure organisationnelle que les synonymes de Spotify et ne sont pas attachés à une manière de travailler qui a échoué pour son créateur.

Faites ceci à la place

(Je plaisante. Il n’y a pas de solution miracle.)

Vous avez peut-être découvert le modèle Spotify parce-que vous cherchiez comment structurer vos équipes. Ne vous arrêtez pas là. Continuez à chercher. Des leaders de société qui ont résisté à des temps de tests plus longs ont écrit bien plus que ce que Spotify a bloggué. Les humains ont tenté de trouver comment travailler ensemble depuis aussi longtemps qu’il y a eu des humains. L’age industriel et l’age de l’information a changé certaines contraintes, mais les chercheurs étudiant les théories organisationnelles ont trouvé des vérités intemporelles sur ce dont les humains ont besoin pour réussir en collectif.

Il s’avère que Spotify n’avait pas trouvé en 2012 comment maintenir la vitesse et l’agilité d’une petite équipe dans une grande organisation. La société a évolué au-delà de son modèle éponyme et a regardé en dehors d’elle-même pour trouver de meilleures réponses. Vous devriez aussi.

Quelques-unes de mes recommendations liées aux sujets couverts par la manière de travailler à Spotify :

• Plus de 200 personnes dans votre organisation produit ? Le Scaled Agile Framework a bien fonctionné pour Fitbit quand j’y ai travaillé.
• Moins de 200 personnes ? Shape Up by Basecamp est la manière dont j’ai l’intention de structurer ma prochaine startup.
• Essential Scrum by Kenneth S. Rubin
• Team Topologies by Matthew Skelton and Manuel Pais

Notes et citations

¹: Scaling Agile @ Spotify whitepaper, Spotify Engineering Culture video

²: Anders Ivarsson et Henrik Kniberg, auteurs du livre blanc « Scaling Agile @ Spotify ». Henrik a clarifié son statut de créateur en 2015: “les gens semblent parfois faire la supposition que j’ai inventé le modèle Spotify. Et bien, ce n’est certainement pas le cas ! Je ne suis que le messager. … Le modèle Spotify est le résultat de la collaboration et de l’expérimentation dans le temps de beaucoup de personnes et de nombreux aspects du modèles ont été inventés sans mon implication. Je ne voudrais certainement pas prendre le crédit des personnes impliquées.”

³: Episode 112: Inside Spotify with Anders Ivarsson, The Agile Revolution, 2016

⁴: You can do better than the Spotify model by Joakim Sundén, 2017 video, slides

⁵: How things still don’t quite work at Spotify and how we’re trying to solve it by Jason Yip, 2017 video, slides

⁶: Balancing Autonomy with Accountability by Edwin Dando

Ressources additionnelles

Si 2 200+ mots d’expériences de première main de 4 employés de Spotify n’ont pas été suffisants, lisez comment le modèle Spotify a échoué pour ces personnes en dehors de Spotify.

• How to Structure an Engineering Team for Scale by Yotam Hadass
• You want to adopt the “Spotify Model”? I don’t think it means what you think it means! by Willem-Jan Ageling
• Spotify sucks! by Erwin Verweij
• Don’t do the Spotify Model! by Udhesh Vivekanandan
• There Is No Spotify Model for Scaling Agile by Anthony Mersino